我有十八年寫 Java 的經驗。跟你們講這件事，並不是要強調我很有經驗，而是要告訴各位：我是在浪費我的時間。(編按：如果改用 Clojure 寫的話，同樣的程式用 1/3 不到的時間就有機會寫完。)

-- Rich Hickey (Clojure 語言發明人)

在 2019 年以前，我並沒有好好地研究過 BI (Business Intelligence) 又或是資料分析 (Data Analysis)、資料工程 (Data Engineering) 等相關問題。大部分的職涯是在新創公司當 backend/fullstack engineer ，有一回，我得到一個工作機會，以約聘雇的身分，到一家位於台北市內湖區的科技公司上班，幫業務部開發一套軟體系統。這家公司的軟體是 L 開頭的，就叫它 L 社吧。

找我去的人，是 L 社業務部的 BI 主管。面談的那一天，他簡單地講了他的需求，講得也模模糊糊的，事後來看，他只講了整個系統的 10% 不到的需求。我聽完就先回答了對該需求的看法，然後，順便展示了一下，之前寫的程式。

『你下個禮拜可以來上班嗎？』面露『祟拜神色』的 BI 主管問道。

唉，我這個人其實非常地誇不得，我居然就這樣子胡亂地答應了一個專案，也沒有確切地把握，該專案是否有在我的能力範圍之內。

這個專案，到了它完成之後，我才了解，我所解決的問題，嚴格地來講，是資料工程 (Data Engineering) 的問題。

由於當年我真的不懂 BI, Data Analysis, Data Engineering，所以我只應用了應用軟體開發 (Application Programming) 的技巧來硬做。由於沒有充分地利用當時已經存在最好的技術，我花了整整 180 天，才勉強抵達終點。如果現在讓我重做一次，60 天就可以做完。

上述的這個故事，重點並不是要講我很有經驗，而是，我是在浪費我的時間。

軟體需求

業務部需要一套軟體，來輔助業績的計算與考核、商業分析。該軟體主要由三大核心功能所構成：

1. 客戶認列功能
2. 業績歸因功能
3. 商業洞察功能

客戶認列功能

L 社的業務部有約 100 名員工，部分的員工是輔助銷售的角色，可能是做報表整理、核對發票、審核廣告、設計新的產品等等。而，銷售的角色，也就是業務們，是該軟體服務的主要客群。這套軟體的重要功能之一，自然也就是要輔助計算業務的績效獎金。

在每一季，業務可以認列自己要專注開發的 20 大客戶、這個認列的過程，在沒有軟體輔助時，就是用 Email 進行。BI 部門會審核業務的申請認列，因為要確保客戶不會被重複認列。此外，如果業務覺得自己認列的某一客戶，跟自己的『氣場不合』，他也可以申請放棄該客戶，轉而申請去認列其它客戶。

如果業務 A 在第一季的 2月１日，認列了客戶 M，那客戶 M 從２月１日之後對 L 社採購的業績，都算是業務 A 的功勞。

業績歸因功能

要計算業績，首先要有資料來源。L 社是一間跨國企業，光是台灣公司就有近一千人。此外，由於公司曾經快速地暴發成長過，公司每開發新的產品線，有時候就也做出新的財務計算系統。總之，這套軟體需要取得來自四個不同財務系統的業績資料。

想當然爾，來自四個財務系統的業績資料，格式長得不會一樣，所以該軟體也要有一個有彈性的格式，可以表示四種不同來源的資料。

當資料匯整之後，就可以依照日期、業務的認列、還有三個不同的業務團隊特有的認列規則，計算出每一位業務可以歸因的業績。

商業洞察功能

除了業績資料、業務對客戶的認列資料之外，這個系統還要可以匯入許多其它的資料，比方說，客戶的資料。

客戶的資料其實是個很模糊的概念，大家可能會想，不就是：「公司名、統編、連絡方式這些嗎？」

不不，沒有這麼單純。像公司的行業別這種資料，對於之後要做出商業洞察，就很重要。所以『公司的行業別』這類資料，就要另外人工準備，再設法輸入系統。

在真正的商業應用環境裡，由於是跨國企業的關系，我的同事還必須設法去區分，哪些訂單是發生在日本的、卻可以算成台灣的業績，哪些訂單是發生在台灣的、卻可以算成日本的業績之類的事。

在匯整了眾多不同來源的資料之後，這個系統要輸出一張大表 (one big table)，這個表格可以用 CSV 格式下載，用來讓商業分析師來設法做出商業洞察 (business insight)。

註：此處的詞彙 --- 大表 (one big table)，大家可能覺得有點困惑。如果是軟體工程師的話，我們會叫它「資料庫反正規化」(denormalization format)，我一開始都很堅持要這樣子說，然而，過了很久之後，我發現無論是台灣的或是國外的資料分析師，都比較喜歡講大表 (one big table)。

軟體實作

這個軟體，在實作上，它可以分成兩個部分：

1. OLTP 部分。OLTP (Online transactional Processing) 的部分是客戶認列功能模組部分。它是一個有 UI 的系統，它會有 user account 的功能，讓業務可以登入系統，去認列每一個業務想要的 20 大客戶。業務提出申請之後，BI 團隊的人有 admin account ，BI 團隊的人可以做審核。審核批過之後，就會生成「業務與客戶的認列關連資料」
2. OLAP 部分。OLAP (Online Analytical Processing) 的部分是以圖中央綠色的資料庫為核心，先匯總所有的資料，然後對這些資料做處理，進而產生業績歸因資料與商業洞察資料的部分。

OLTP vs OLAP

前文有提過，我浪費了很多我的時間。我實作這套軟體系統的時候，並沒有把 OLTP 與 OLAP 之間的差異性，想得特別清楚，總之，我就是一直寫下去。Application Programming 大多數是處理 OLTP 的問題。換言之，我寫「客戶認列模組」的部分，大致上還中規中矩，然而，離開了左下角的那個小小齒輪之外的部分，卻沒有去應用當代最先進的資料工程技術來處理，這就是我的錯了。

其它資源

1. 對 dbt 或 data 有興趣 👋？歡迎加入 dbt community 到 #local-taipei 找我們，也有實體 Meetup 請到 dbt Taipei Meetup 報名參加
2. 歡迎訂閱 PruningSuccess 電子報，主要談論軟體開發、資料處理、資料分析等議題。